fix(platform): repair failures found in Cloudflare acceptance - #569

…an old secret version

Try the automatic app rollback without force first, as Wrangler's
rollback does. Only when Cloudflare answers 10220 (a secret changed since
the previous version was active), read the owner again and retry with
force, so a secret changed outside Void is not overwritten and any other
Cloudflare check still applies.

Keep the trigger-sync rollback and the platform installer unforced. The
first returns to the version that served traffic seconds before, so a
10220 there comes from someone else. The second would undo voidzero-dev#569: a
credential update rolls forward instead of restoring old secrets.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

…an old secret version

Try the automatic app rollback without force first, as Wrangler's
rollback does. Only when Cloudflare answers 10220 (a secret changed since
the previous version was active), read the owner again and retry with
force, so a secret changed outside Void is not overwritten and any other
Cloudflare check still applies.

Keep the trigger-sync rollback and the platform installer unforced. The
first returns to the version that served traffic seconds before, so a
10220 there comes from someone else. The second would undo voidzero-dev#569: a
credential update rolls forward instead of restoring old secrets.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

Cloudflare refuses a deployment that moves traffic back to an older
Worker version when a secret has changed since that version was active
(error 10220), unless the request is forced. Void's automatic recovery
runs into this. After a failed readiness check, activation or trigger
sync, it deploys the previous version at 100%. Cloudflare rejects that,
the Worker stays at the previous version at 100% plus the failed one at
0%, and the next deploy stops with `deployment-changed` until someone
fixes the deployment by hand.

```
before
  deploy v2 (changes a secret) → readiness fails → restore v1@100
    → Cloudflare 10220 ✗ → stuck at v1@100 + v2@0, next deploy refuses

after
  deploy v2 (changes a secret) → readiness fails → restore v1@100
    → Cloudflare 10220 → Void still owns traffic? ── no ──→ stop ('unsafe')
                                   │ yes
                                   └→ restore v1@100 with force ✓
                                      → error says: old secret values are live,
                                        deploy again to apply the new ones
```

## What changed

- `versions.deploy` gets an optional `bypassDeploymentChecks`. Both cf
runners pass it as `--bypass-deployment-checks`, which sends
`force=true` to the Deployments API.
- `restorePreviousVersion` (readiness, uploader-check, activation and
trigger-sync failures) first tries the restore without force. Only when
Cloudflare answers 10220 does it read the owner again and retry with
force. Wrangler's own rollback does the same: it tries without force and
forces only after a 10220.
- When the restore had to be forced, the activation result carries
`restoredOlderSecrets: true` and the deploy error adds:
> Cloudflare refused to restore the previous version because this deploy
changed a secret, so Void forced the restore. The previous version runs
with its old secret values; deploy again to apply the new ones.

| Deploy | Forced? |
|---|---|
| normal deploy, staging, activation | never |
| `void rollback` (user asked for it) | never |
| automatic app rollback (`restorePreviousVersion`) | only on retry
after 10220, if Void still owns traffic |
| trigger-sync rollback in `activateCloudflareExistingVersion` | never |
| platform installer activation and restoration | never |

### Why the last two are not forced

- **Trigger-sync rollback:** it goes back to the version that served
traffic seconds before, and Cloudflare had just accepted the user's
rollback without force. So a 10220 there means someone else changed a
secret in between, and Void must not overwrite that.
- **Platform installer:** #569 decided that a credential update is never
rolled back to versions holding the old secrets. Traffic stays closed
and the next run rolls forward (see the comment in
`platform-installer.ts` and the test "rolls forward a partially restored
credential update"). Forcing `restorePlatformWorkerDeployment` would
undo that for the one Worker whose trigger or domain publish failed, and
put it back on the old, possibly revoked, API token. Without a
credential update, Void's own platform deploys don't cause a 10220.

## Where this applies

The app path is the one that hits this: a deploy whose new version
changes a secret and then fails readiness, activation or trigger sync. I
found it in a fork that publishes prebuilt artifacts with explicit
secrets. With this change, the same live run on Cloudflare restored the
previous version and the next deploy went through.

## Tests

- `operations.test.ts` runs every recovery path (readiness, activation,
triggers; with and without `preserveTriggers`) in 4 cases:
  - Cloudflare accepts the restore: nothing is forced.
- Cloudflare refuses with 10220: one unforced try, an owner read, then
one forced retry, and `restoredOlderSecrets: true`.
- 10220, and someone else deployed in between: result `unsafe`, no
forced retry.
  - Any other error: result `failed`, no retry.
- `cloudflare-deploy.test.ts` checks that the readiness, trigger and
uploader errors add the old-secrets line only when
`restoredOlderSecrets` is set.
- `cloudflare-operations.test.ts` checks that the trigger-sync rollback
and user rollbacks are not forced. `platform-install-cutover.test.ts`
checks that no platform activation or restoration is forced.
- One test runs the real pinned cf (1.0.0-beta.18) against a local
server and checks that `?force=true` is sent next to the deployment
body.
- Mutation checks, each caught by at least one test: always force, never
retry, retry on any error, skip the owner re-read, force the
trigger-sync rollback, force the platform restoration, force the
platform activation, drop or always set `restoredOlderSecrets`, drop it
on the trigger path, skip the message line.
- `vp fmt`, `vp lint`, the `deploy-cloudflare` and `void` typechecks,
and `vp run test --base origin/main` pass.

## Known limits

- Cloudflare describes `force` only as skipping checks "such as" the
secret one. This PR forces only after Cloudflare answers 10220, so force
is used only in the case Cloudflare names.
- Between Void's owner read and the forced retry there is still a short
gap, about one cf process start. The Deployments API has no
compare-and-set, so it can't be closed fully. That gap already exists
for every deploy Void makes.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: LongYinan <github@lyn.one>
Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>